A JSP is, so to speak, an HTML page in which a Java (trademark) program is embedded. The JSP is located on a Web server, whereby an HTML page in which the Java (trademark) program is expanded is provided for a client in response to a request from the client. That is, the JSP is compiled into Java (trademark) codes in a servlet format and executed when a first request has been made. Thereafter, the JSP is resident in memory in the compiled state, and is executed immediately in response to a request for the second time or later.
In the JSP, a Javax.servlet.jsp.JSPWriter object exists behind using “out” as a variable name. All outputs are transmitted to the client as HTTP responses through this object. An output is not directly written into an output stream of a Javax.servlet.http.HTTPServletResponse object. One reason for this is the need to buffer an output. That is, in the JSP, there are cases where an output already executed is canceled to perform another process. For example, when <jsp: forward page=“foo.jsp”> is executed, an output before the execution of this is canceled, and control is transferred to foo.jsp. For such a case, an output needs to be stored in a buffer without being transmitted immediately.
Furthermore, JSPWriter is not a subclass of Java.io.OutputStream but a subclass of Java.io.Writer. That is, the data which JSPWriter stores in the buffer is not a byte array but a character array. The reason for storing a character array is generally that a servlet transformed and compiled from a JSP does not know what code conversion should be performed for the servlet to write into an output stream of an HTTPServletResponse object.
For example, suppose that foo.jsp as shown in FIG. 36 includes bar.jsp as shown in FIG. 37. In this case, the initial character code is ISO-8859-1 designated by foo.jsp. However, bar.jsp can change it to Shift_JIS under the JSP specifications, unless the buffer has been flushed. For the above-described reason, in a JSP, text is handled as not a byte array but a character array.
That is, in ordinary JSPs, a character code set for each language, e.g. Shift_JIS or the like in the case of Japanese, is used for any one of or both of page character encoding and response character encoding; in many of internationalization-ready JSPs, UTF8 is used for any one of or both of page character encoding and response character encoding. On the other hand, inside Java (trademark), UTF16 is used for character encoding. Accordingly, when a JSP is compiled, text in the JSP is transformed into UTF16. Consequently, when a JSP is executed, response character encoding needs to be performed for each response.
As described previously, in a Java (trademark) program in execution, characters expressed as a byte stream in the outside is transformed into a character stream to be processed. Accordingly, when a document is outputted, a character stream needs to be transformed into a character set specific to each application. This response character encoding unexpectedly takes a long time. This is a factor in reducing the speed at which a JSP is executed.